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(57) Abstract 



A system and metfuxl for efTectively retrieving and man- 
aging network data ftom diousands of network elements by 
providing a graphical user interface to a netw<vk management 
system that permits shared ^cess by service provider person- 
nel using divcne computer equqmiem distributed over a wide 
geographical region. User requests to die network manage- 
ment system are input via any one of a phmdity of w(Hksta- 
tiocu (702. 704, 706) coupled with the conpany-wkle Intranet 
(708). Usen can submit batch or on-line requests. Batch 
requests are scheduled to be processed at a later time and on- 
line requests are proccased immediately. Results from on-line 
requests are available to the user as soon as the request has 
been processed. 




FOR THE PURPOSES OP INFORMATION OtLY 



Code, used to identify Slateii»iiyu>thePCTontliefromp,gesof pamphlels pubUshing intenuuioiul appUniiou inter the PCT. 



AL 


Abmift 


IS 


AM 


Annonu 


n 


AT 


Auifla 


FR 


AU 




GA 


AZ 


AseriMiuui 


GB 


BA 


Bonis ndHenetovhi 


GB 


BB 


Bvtedn 


GH 


BE 


Bclghn 


GN 


BF 


Buffefaia Paio 


CR 


BG 




HU 


hj 


Benin 


IE 


BR 


Bnzii 


IL 


BY 


Belanit 


IS 


CA 


CoMdt 


IT 


CF 


Gentnl AlHuB RqMhtic 


JP 


OG 


Congo 


KE 


CH 




KG 


a 


Caied*I«ote 


iCP 


CM 


Ctmeraan 




CN 


Cikiaft 


KR 


CU 


Cob« 


KZ 


CZ 


Czech Republic 


LC 


DE 


OcnMay 


U 


DK 


Dconuric 


LK 


EE 




LR 



GCQIglft 



Irelnd 
bnel 



Italy 

Kenya 
KyigynUD 
Dcmoottic People'f 
RcpobUcofKoRa 
RcpiiblicorKcati 



Sri 



LS 

LT 

LU 

LV 

MC 

MD 

MG 

MX 

ML 

MN 

MR 

MW 

MX 

NE 

NL 

NO 

NZ 

PL 

PT 

RO 

RU 

SO 

SE 

5G 



LMfk 
Mouco 

RcptibficorMoUova 



lliefBnMrY^lM 
RcfRMIeon 
Mali 



Murittnia 



Msko 
Niger 

NeUvrlmda 



SI 




SK 


StovaUa 


SN 


Senegal 


8Z 


Swastlaad 


TD 


Chad 


TO 


Ibgo 


TJ 




TM 




TR 


IMtey 


TT 
UA 


IMdadi^Tofa^ 
UfaaiM 


UG 


Ufuda 


US 


United Sotet of America 


Ul 


UibeUiiM 


VN 


VIelNm 


YU 




tw 





Hew y^aland 

PpUb^ 

Ponugtl 



Ruuian Mentioa 
Sudan 
Sweden 
Singapore 



WO97/SQ210 



PCTAJS97/11007 



Intranet Graphical User Interface For SONET Network 

Management 

Background of the Invention 

Field of the invention 

The present invention relates generally to teleconununication network 
management, and more ^ecifically is directed toward a system and method for 
increasing the visibility and availability of network element data to a service 
provider. 

Related Art 

There is an ongoing need to improve network monitoring and 
management techniques at all levels, from the network element level up through 
the highest system level. Network elements are monitored to provide a detailed 
predefined set of networic element performance data. Examples of performance 
data and alarm information that can be retrieved from a network element include 
the number of errored seconds, severely errored seconds, path alarm indication 
signals, etc. 

FIG. 1 illustrates an example of a conventional vendor-controlled network 
management system 100 that retrieves network perforaiance data from, and 
configures a group of network elements 110. in this network management 
system, the operations controllor (OPC) 130 is connected to the network elements 
101 and 104 via Control Network (CNet) connections 122 and 124, i«spectively. 
The network elements 101-104 are referred collectively as the OPC span of 
control, or OPC group 1 10. The network elements 101-104 are interconnected 
by links 111-113. Links 111-113 represent either intrasite or intersite 
connections. Intrasite connections can be provided by CNet bridge cables, while 
intersite connections can be provided via the synchronous optical network 
(SONET) defined data communications channel (DCC) overhead bytes. 

For the network monitoring operation, the OPC 130 periodically 
interrogates the computer resident within each network element 101-104. The 
network elements 101-104 provide the OPC 130 with performance and status 
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infonnation. The OPC 130 then provides the collected infonnation to the 
network manager 140. The network manager 140 retrieves perfomiance and 
status infonnation from a plurality of network element groups via a pluiality of 
OPCs (not shown). 

In a similar fashion, the network manager 1 40 is also used to configure the 
network elements 10M04. Examples of types of configuraUon settings that can 
be accomplished in this fashion include switching the performance alarms to an 
W or 'ofT state, and setUng the threshold parameters used to activate the 
perfoimance alamis. From the network manager 140 a command is provided to 
the OPC 130 that is used to configure one or more of the network elements 101- 
104 within the OPC group 1 10. 

In this conventional network management system 100, the service 
provider (e.g.. MCI Telecommunications CoTx,mion) owns and controls the 
network elements 110. the OPC 130 and the network manager 140. However, 
the service provider does not control the contem and distribution of the retrieved 
performance data. Rather, the network elemem vendors that sell the hardware 
(i.e. the network elements 110. the OPC 130 and the network manager 140), 
retain cortrol over both the network managemem software and the collected data' 

Specifically,network elements 101-104 are programmed by the vendor toprovide 
only basic predefined infom«ttion to OPC 130. The .Grieved data is then stored 
.n a databases located in the OPCs 130 and the network elements 110. Such 
databases are also controlled by the vendor. Finally, the vendor generates 
Picdefmed reports that are provided to the service provider on a network elemem 
basts. Effectively, vendors dictate both the type and format of data that is 
provided to the purchasers of the network elements. 

In this situaUon. a service provider has limited access to its own network 
data. Customization of the data to be retrieved and the provision of aggregate 
network-wide reports can be accomplished only through requests to the vendor 
This request process is often inefficiem and expensive. What is needed is a 
system and method for maximizing (1) the types of data that are extracted from 
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the network elements, and (2) the availability of the extracted data to the service 
provider for subsequent analysis. 

In addition, in the conventional network management system 100, each 
network element must be configured manually. That is. a network engineer must 
manually log on the network manager 140 or OPC 130 and send a set of 
commands to each of the network elements 101-104 that is to be configured. 
Alternatively, network engineers can configure the network elements 101-104 by 
locally attaching a temiinal to each of the network element's craft interface (not 
shown, described below), and manually configuring the network elements 101- 
1 04. In either case, both conventional methods involve manually configuring 
the networic elements, one at a time. The conventional method does not provide 
a networic-wide solution. Considering that a typical long distance network 
comprises many thousands of network elements 101-104. the conventional 
method of network configuration can be an extremely costly and timely process. 

Moreover, the conventional method makes it very difficult to maintain 
a consistent configuration for the many thousands of network elements 101-104 
comprising the communications network. For example, it is desirable to set 
consistem alarm thresholds for similar types of network elements throughout the 
network in order to yield more accurate and uniform performance evaluation 
results. What is needed therefore, is a system and method for automatically 
configuring the network elements so that a timely and consistent configuration is 
assured throughout the network. 

Additionally, it is desirable to permit shared access to a network 
management system that is available to service provider persomiel throughout a 
wide geographical area. Further, it is desirable that such shared access be 
available to a diverse variety of computer systems. What is needed therefore, is 
a system and method for providing shared access to a network management 
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system to a diverse variety of computer platforms distributed over a wide 
geographical area. 

Summary of the Invention 

The present invention satisGes the above menUoned monitoring needs by 
providing a network management system that is controlled by the service 
provider, by providing a network management system that automatically 
configures the netwoik elements, and by providing a graphical user interface that 
provides shared access to a network management system for a wide variety of 
diverse computer systems distributed over a large geographical area. 

The network managemem system of the present invention comprises a 
plurality of controllers that communicate with a desired network elemem via a 
switch 56 network. In a preferred embodiment, the network is divided into one 
or more data communications channel (DCC) groups that include one or more 
network elements with ciaft interface ports directly connected to the switch 56 
network. 

In a preferred embodiment, the nctworic management system is 
interconnected via a local area network. User requests are initiated ftom a 
plurality of workstations that are coupled with a company-wide Intranet. A web 
server interfaces between the company-wide Intranet and the netwoik 
management system. Any authorized user can access the network management 
system via a standard web browser program that communicates with the web 
server via HyperTcxt Transfer Protocol (HTTP). Such programs are generally 
available for a wide variety of computer platforms. Hyper-Text Markup 
Language (HTML) is used by the web server and web browser to provide users 
with a graphical user interface (GUI) to the network management system. 

Accordingly, users can view pre-defined reports of network elements by 
navigating through a series of HTML web pages from any workstation comKjcted 
to the Intranet. For example, in a typical implementaUon of the present invention, 
perfomiance inforaiation from network elements are collected on a daily basis. 



WO97/S0210 



PCT/US97/11007 



-5- 



Typically, pre-fonnatted HTML perfonnance reports are sent to the web server 
so that they are available to service provider personnel via the Intranet. 
Accordingly, any user that has access to an Internet terminal can view the latest 
pcrfoimance data from any network element by traversing HTML pages in a well- 
known manner. 

Additionally, authorized users throughout the geographical realm of the 
service provider can make requests that are either processed immediately (on-line 
requests), or are processed at a later time (batch requests). User requests can be 
monitor or configuration requests. Generally, HTML is used to provide users 
with intuitive tools for finding specific information used to view reports and/or 
submit requests. 

A monitor request includes information that identifies a network element 
and the type of infomiation sought to be retrieved from the network element. A 
configuration request includes information the identifies a network element and 
the configuration information. Based upon Uie request, the network management 
system identifies a DCC group that includes the network element. Next, the 
network management system identifies one of the network elements in the 
identified DCC group that has a craft interface port directly connected to the 
switch 56 network. 

After this identification process, the network management system directs 
a controller to initiate a call to tiie network element having a di«K:t connection to 
the switch 56 network. Th«)ugh this connection, the controller can access any 
other network elemem within the DCC group. The data retrieval process and/or 
configuration process begins after tfie desired network element is accessed. 

Configuration and data retrieval is facilitated by the controller's emulation 
of a VTl 00 terminal. After navigating tiirough a series of craft interface menus, 
Uie controller sends configuration data to the network elemem. In case of data 
collection, the controller extracts the desired data from the screen display data 
that is received from the network element. The extracted data is stored in a 
database. Infonnation from tfic database is available to a web server so Uiat the 
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infonnation is accessible by any user associated with the service provider from 
an Intranet tenninal. 

The foregoing and other features and advantages of the invention will be 
apparent from the following, more particular description of a preferred 
embodiment of the invention, as illustrated in the accompanying drawings. 

Brief Description of the Figures 

In the drawings, like reference numbers indicate identical or functionally 
similar elements. Additionally, the left-most digit of a reference number 
identifies the drawing in which the reference number first appears. 

FIG. I illustrates a conventional network management system. 

FIGS. 2, 3 and 7 illustrate a network management system according to the 
present invention. 

FIG. 4 illustrates an example of a series of menus that are navigated 
through the craft interfiice of a network element. 

FIGS. 5, 8-12 illustrate flow charts depicting various processes that can 
be used in a preferred embodiment of the present invention. 

FIG. 6 illustrates a block diagram of a computer useful for implememing 
elements of the present invention. 

Detailed Description of the Preferred Embodiments 

The present invention addresses the general problem of effectively 
retrieving and managing network data that is obtained from thousands of network 
elements under the control of a single service provider. In addition, the presem 
invention address the general problem of effectively configuring the thousands 
of network elements under the control of a single service provider. As noted 
above, the conventional network managemem system 100 is controlled by the 
vendor. The vendor not only limits the type of data that are retrieved by OPC 130 
but also limits the types of reports that are provided to the service provider. With 
this limited amount of infonnation. the service provider camiot optimally manage 
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the network. Modifjcations to this vendor-defined process have proven to be 
expensive, time-consuming and inflexible. 

In addition, the conventional network management system only provides 
for manual configuration of network elements. No system-wide network 
management solution is provided with the conventional method. With this 
limited amount of control, the service provider cannot configure the various 
network elements in an optimal fashion. This has lead to inconsistent 
configurations and in many cases, improperly configured network elements. 
Improperly configured network elements can cause network problems to go 
unnoticed by the service provider. This can lead to more expensive repairs, loss 
of customer satisfaction and loss of revenue for the service provider. 

The present invention is generally designed to inciease a service 
provider's control over the acquisition and analysis of network management date. 
In the acquisition phase, the present invention increases the types of data that can 
be retiieved from the network elements. In the analysis phase, the storage of the 
retrieved data in a service provider controlled database allows tiie service 
provider to more effectively analyze and optimb^ the pcrfoimance of the 
network. In addition, the present invention is generally designed to increase a 
service provider's conttol over tiie configuiation of the network elements. In tiie 
configuration phase, a service provider can configure network elements 
automatically, on a network-wide basis. 

Additionally, the present invention addresses the general problem of 
effectively retrieving and managing network data from thousands of network 
elements by providing a graphical user interface that permits shared access to a 

network management system byadiverse variety of computer systems distributed 
over a wide geographical region. A web server attached to a preferably 
company-wide Inttanet is used to interface witii a network managemem system. 
Remote users throughout tiie company can submit requests and view reports via 
any workstation attached to tiie Intranet. Accordingly, users can view pre-defined 
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reports and submit requests by fiUng out forms and/or navigating through a series 
of HTML web pages presented by the web server. 

FIG, 2 illustrates a preferred embodiment of a customer-controlled 
network management system 200. The network management system 200 includes 
5 a communicaUon network, such as a switch 56 network 260, thai connects any 

one of controllers 271-273 to any network elemem in the service provider's 
network. The switch 56 network 260 is a controlled 56 kbit/s routing network. 
It should be understood that other types of communication networks cou:j be 
used in place of a switch 56 network. A controller 271 -273 initiates a connection 
10 by first dialing the number that is associated with a network element 232, 244 that 

is directly connected to switch 56 network 260. These directly connected network 
elements 232, 244 allow access to any networic element in data communications 
channel group (DCC) 210. 

In this example, each controller 271-273 has preferably eight ports in 
1 5 which to connect to switch 56 network 260. In combination the controllers 27 1 - 

273 can make 24 simultaneous calls to the network elements scattered throughout 
the network. In an alternative embodiment, the controllers 271-273 are connected 
to the netw(M-k elements 222, 224 via a private-line network. 

The network management system 200 also includes a scheduler 282, a 
20 reporter 286, a server 284 and a database 290. The scheduler 282 coordinates 

user monitor or configuration requests for the controllers 27 1 -273. The reporter 
286 generates customized reports that are based on the collected information tiiat 
is stored in database 290. These customized reports are defmed by the service- 
provider. Finally, tiie server 284 coordinates tiie data retrieval and analysis 
25 processes that are initiated by user requests. 

As illustrated in FIG. 3, switch 56 network 260 permits the controllers 
271-273 to directly connect to a subset of network elements that are scattered 
throughout a national network. This subset of network elements provides a 
connection poim between controllers 271-273 and the network elements witiiin 
tiie various DCC groups. FIG. 2 illustrates an example of a single DCC group 
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210. DCC group 210 includes a plurality ofOPC groups 220, 230, 240. OPC 
groups 220, 230, 240 are interconnected by communication links 252, 254. 
Communication links 252, 254 can represent a communication channel 
established via the SONET DCC overhead bytes. As defined in the context of 
network management system 100. each OPC group 220, 230, 240 is associated 
with a singleOPC 130. For convenience, only OPC 130 associated with network 
element group 240 is shown. 

The OPC groups 220. 230, 240 each include a plurality of network 
elements. The OPC group 220 includes the network elements 222 and 224. the 
OPC group 230 includes the network elements 232 and 234, and the OPC group 
240 includes network elements 242 and 244. With refcttsncc to the OPC group 
240, the OPC 1 30 interfaces with the network elements 242 and 244 via the CNet 
ports 246 and 247, respectively. As noted above, the CNet ports 246 and 247 
allow the vendor-controlled OPC 130 to retrieve a basic vendor-defined 
information set from each of the network elements in OPC group 240. In 
addition, the CNet ports 246 and 247 allow the vendor controlled OPC 130 to 
configure each of the network elements in the OPC group 240. 

In contrast to the vcndor-conm)lled interface via the CNet ports 246 and 
247, network management system 200 interfaces with the network elements in the 
DCC group 210 via the craft interface ports 226 and 248 on the network elements 
232 and 244, respectively. One or more connection points between the switch 56 
netwoik 260 and a DCC group can exist The craft interface ports 236 and 248 
represent tiie connection points between controllers 271-273 and each of the 
network elements 222, 224, 232, 234, 242, 244 in the DCC group 210. In oUier 
words, the connection points at the craft interface ports 236, 248 allow the 
controllers 271-273 to interrogate tiie computer ti»at is resident in any network 
elements in tiie DCC group 210. This metiiod of interrogation capitalizes on tiie 
provision of internal data processing capabilities witiiin each of tfie network 
elements. In addition, tiie connection points at tiie craft interface ports 236, 248 
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allow the controllers 271-273 to configure the computer that is resident in any 
network element in the DCC group 210. 

As noted above, communicaUon between the various OPC groups 220, 
230, 240 inthe DCC group 210 is provided by the links 252, 254. The links 252, 
254 can be implemented using the SONET DCC overiiead bytes. In the preferred 
embodiment, a DCC group can include over a hundred network elements. In 
effect, the various communication links within the DCC group 210 allow the 
computers within the network elements to operate as a local area network (LAN). 
To access a particular DCC group, the controllers 271-273 need only dial a 
number associated with a network element that is directly connected to the switch 
56 network 260. Thereafter, the controllers 271-273 are provided with complete 
access to any of die network elements in the chosen DCC group. 

In the network management mode, through the use of the craft interface 
at network element ports 236 and 248, the controllers 271-273 are allowed to 
retrieve significantly more information from a netwoik element as compared to 
OPC 130. For example, in addition to the predefined set of alarm and 
performance data, the controllers 271-273 can also retrieve card level inventory 
data (e.g., serial numbers and software versions), tributary layout information, 
laser bias information, etc. Effectively, all information known to the networic 
element computer is retrievable via craft interface ports 236, 248. 

Generally, any authorized user associated with the service provider 
organization can direct one of controllers 271-273 to query a specific network 
element within the service provider's network. In addition, any authorized user 
associated with the service provider organization can direct one of controllers 
271-273 to configure a specific network element within the service provider's 
network. 

FIG. 5 illustrates a flow chart of the user-initiated query or configuration 
process. First, at step 502. a user sends a request to the scheduler 282 for access 
to a particular network element. This request includes information that identifies 
a network element. In addition, for a query operation the user specifies the type 
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of network management data that is sought to be retrieved from the network 
element. For a configuration operation, the user specifies configuration data for 
the n^work element. 

In one embodiment, the scheduler 282 uses the received request to 
generate a series of insUuctions that allow a controller 271-273 to navigate 
through a series of menu screens. In an alternative embodiment, the request itself 
includes script infoimation that directs a controller's navigation through a series 
of menus screens. The use of menu screens to retrieve network element data and 
to configure network elements is described in greater detail below. 

In one example, a user may request information on the operating condition 
(e.g., laser bias information) of a specific network element. In other examples, 
a user may schedule a series of periodic requests that seek to gather information 
from a group of network elements. These periodic requests may seek to gather 
card-level inventory infonnation, tributary layout infonnaUon, etc. from all of the 
network elements in the network for tracking puiposes. In either case, the 
scheduler 282 processes the requests by identifying the connections to be made 
by controllers 271-273. In yet another example, a user may request to tun>.on an 
optical performance alarm, or may request that new threshold parameters be set 
to trigger an optical performance alarm. 

At step 504, the scheduler 282 identifies the DCC group in which the 
network element specified by the user resides. Next, at step 506, the scheduler 
282 identifies one of die network elements in die DCC group that is directly 
connected to switch 56 netwoik 260. In the example of FIG. 2, the network 
elements 232 and 244 of DCC group 210 are directly connected to switch 56 
network 260. Each of these directly connected network elements is assigned an 
identifying number that is used by controllers 271-273 in making a call. 

At step 508, the scheduler 282 instructs one of die controllers 271-273 to 
make a call to a directly connected network element. Communication with the 
directly connected network dement allows one of controllers 271-273 to access 
the information from, or configure any of the network elements in die DCC 
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group. TTiis access is provided by the LAN-like conHguration that is created by 
the communication links that inteicomiect the network elements in the DCC 

group. Once communication has been established with the network element the 
controller 27 1 -273 can then retrieve any data that may be requested by the user 
or the controller 271-273 may configure any of the network elements within the 
DCC group 210. This process is represented by step 510. 

The retrieval and/or configuration process at step 510 is facilitated by the 
emulation by controllers 271-273 of a VTIOO terminal typically used in a craft 
interface connection. Through this emulation process, a controller 271-273 can 
navigate through a series of menu screens to identify the menu option that will 
produce the data requested or produce the configuration results requested by the 



user. 



It should be appreciated that the method described above, with reference 
to FIG. 5, can be used to monitor and configure network elements on networic- 
wide basis. For example, the scheduler 282 can be programmed to perform 
periodic jobs that direct the controllers 271-273 to visit each network element 
within the telecommunications networic. in a manner as described above. In this 
fashion the performance of the entire telecommunications network can be 
monitored in a periodic and consistent fashion. For example, nightly 'walk- 
abouts' can be scheduled so that networic-wide performance data is available to 
the service provider on a daily basis. 

In a simibr fashion, the scheduler 282 can be programmed to perform 
penodic configurations on a networic-wide basis. For example, it may be desired 
to periodically turoK,nperfbm,ancealamis. Alarms that are switched off. for one 
reason or another, will cause performance problems to go unnoticed. Alarms that 
have been inadvertently switched-off have proven to be troublesome for the 
telecommunications industry. In many cases, alarms are never turned on 
m newly deployed networic elements. Thus, the present invention can be used to 
systematically turn on all desired alarms within the entire telecommunications 
network. This process can be repeated on a periodic basis, to assure that alarms 
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are turned on for newly deployed network elements and for any other network 
elements in which alarms are inadvertently switched-ofT. 

Additionally, the present invention can be used to set alarm threshold 
parameters for network elements on a network-wide basis. This will assure that 
consistent parameters are used throughout the network in order to increase the 
accuracy and reliability of the performance reports on a network-wide basis. 
Once again, this process can be repeated on a periodic basis to assure that 
consistent values for all network elements within the network. In addition, this 
process can be repeated whenever it is desired to change the values of the alarm 
threshold parameters. This aspect of the present invention facilitates 
experimentation with the alarm threshold parameter values, so that optimal values 
can be determined. 

An example of a sequence of menu screens 410, 420, 430, 440 used in the 
communication between controllers 271-273 and the networic elements is 
illustrated in FIG. 4. In this example, a data request is being processed through 
a series of pre-defined menu screens 410-440. The menu scimis 410-440 are 
typically defined by the vendor. Starting at menu screen 410, a controller 271- 
273 automatically selects the type of information to be extracted. In this example 
the options include alarm information (3), performance monitoring information 
(6), protection information (10), facility information (16), etc. 

In the example of FIG. 4. a controller 271-273 automatically chooses in 
sequence, the choice of the performance monitoring option (6) in menu screen 
410, the &cility performance option (16) in the menu screen 420, and the history 
option (10) in the menu screen 430. At menu sci«en 440, the controller 271 -273 
is presented with various perfomiance monitoring parameters that can be 
retrieved. For example, controller 271-273 can select the historical data for path- 
level enored seconds (PathES) or path-level severely errored seconds (PathSES). 
After the controller 271-273 selects a specific parameter identified by die user 
request, the computer in die networic eiemem being queried returns a result to be 
displayed on die emulated VTIOO screen. Thus, the controller 271-273 selects 
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the appropriate menu items to perfomi the intended function. If a configuration 
request is desired, such as a request to turn on a performance alarm, another set 
of menu screens (not shown) would be traversed, in a similar fashion as described 
above. 

The resuhs to be retrieved is obtained by a "screen-scraping" method. In 
this process, the controller 271-273 receives data to be displayed on a VTIOO 
screen or other computer display screen. This display data is in a data format that 
includes row position information, column position information, and ASCII 
encoded text to be displayed at the specified row and column positions. Since a 
controller 271-273 knows the position at which the returned resuh is to be 
displayed, the controller 271 -273 can extract the ASCII encoded information that 
is associated with the known row and column position identifiers. Thereafter, the 
ASCII coded information is converted and stored in database 290. 

Note that during the processing of requests, information is typically 
retrieved by the controllers 271-273 via the "screen-scraping" method as 
described above. For example, during the processing of a configuration request 
to set alarm parameters, several menu screens, such as the menu screen 410, are 
typically traversed by the controllers 271-273. Each new menu screen is 
typically analyzed via the "screen-scraping" method to verify the progress of the 
operation. Thus, as the term is used herein, retrieving information from the 
networic elements, not only refers to retrieving result data, such as status 
information associated with a monitor request, but it also refers to retrieving 
menu screen data associated with the processing of any type of request. 

The database 290 stores network element data extracted by the controllers 
271-273 in response to user requests that are generated by any user associated or 
authorized by the service provider. As noted above, most of this network element 
data is notavailable through conventional network management system 100. As 
a further benefit, infoimation stored in the database 290 can be extracted and 
analyzed by any user or group associated with the service provider. Additionally. 
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any user or group associated with the service provider can remotely configure any 
or all of the network elements throughout the entire network. 

Thus, while the network management system 100 typically provides 
performance data reports for specific network dements, the network management 
5 system 200 allows the generation of reports and configuration on a network-wide 

basis. For example, trend statistics can be generated across multiple network 
elements. These trend statistics allow network management to be performed 
properly at a higher network level rather than at the network element level. 

FIG. 7 depicts a more detailed block diagram of a preferred embodiment 
10 of the network manager 200. As shown, the elements comprising the network 

management system 201 are interconnected via a Local Area Network (LAN) 
714. A typical example of a particular LAN that can be used to implement an 
embodiment of the present invention is a NOVELL* LAN. The database 290 is 
preferably shared by the network elements within die network management 
1 5 system 201 . For example, the LAN server 284 is configured so that access rights 

to the database 290 arc granted to the controllers 27 1 -273, the scheduler 282, and 
the reporter 286. 

The controllers 271-273 can be implemented with a general purpose 
computer system. An exemplaiy computer system thai can be used to implement 
20 the controllers 271-273 is described below with reference to FIG. 6. As noted 

above, each controller 271-273 has a plurality of ports to connect to the switch 
56 network 260. This is depicted by the plurality of transmission lines 712 
connected between each controller 271-273 and the switch 56 network 260. The 
number of ports used depends on the specific implementation of the present 
invention. For example a "Digiboard", manufactured by DIGI Incorporated 
comprises 8-16 asynchronous ports for each controller 271 -273. 

In a preferred embodiment of the present invention, the reporter 286 
comprises an Intranet 708, coupled with a web server 71 0 and a plurality of 
workstations 702-706. The web sender 710 is coupled with the LAN 714 of the 
network management system 201 . Typically, a fire-wall or similar device (not 
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shown) is placed between the web server 710 and the network management 
system 201 for security purposes. The firewall prevents the unauthorized 
dissemination of confidential information from the Intranet 708. 

In operation, network management information is presented to the user at 
any one of the plurality of workstations 702-706. In addition, network elements 
can be configured via any one of the plurality of workstations 702-706 coupled 
with the Intranet 706, as described below. 

By using the Intranet 708, the present invention provides a distributed 
means for reporting status from and/or configuring the thousands of network 
elements within the telecommunications network. A particular advantage 
provided by the present invention is that the plurality of workstations 702-706 can 
be spread across a very large geographical region. Further, the use of the Intranet 
708 provides a means for connectivity between the network management system 
201 and a plurality of workstations 702-706 with diverse computer platforms. 
Accordingly, any type of workstation capable of running a commonly available 
Interact Browser program, such as Netscape's Navigator, or Microsoft's Internet 
Explorer, can communicate with the network management system 201. 
Generally, such web browsers communicate with the web servers via a 
communication protocol known as HyperTcxt Transfer Protocol (HTTP). Thus, 
a diverse variety of workstations have access to network element reports and 
real-time requests for tiie monitoring and/or configuration of any of tiie network 
elements tiiroughout the telecommunications network. 

FIG. 8 is a flowchart of a process that illustiates how a user submits an 
on-line request to the network management system 201, from one of the 
workstations 702-704 comiected to tiie Intranet 708 according to an embodiment 
of the present invention. For the purposes of tiiis example, it is assumed that Uie 
user is at tfie workstation 702 and the request is processed by the controller 7 1 2. 
Note however, that any workstation 702-706 coupled witii the Intranet 708 can 
be used to submit such a request. Furtiicr. any controller 271-273 coupled with 
the LAN 714 can be used to process such a request. The number of workstations 
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702-706 and the number of controllers 271-273 that are used to implement a 
speciHc embodiment of the fvesent invention, will vary depending on the needs 
and desires of the service provider. 

The process begins with step 802. In step 802 the user logs onto the 
Internet 708. This step is accomplished in the usual fashion by entering a user ID 
and password from the workstation 702. Note, this step may not be necessary for 
some implementations of the present invention. In step 804 the user jumps to the 
network management on-line request page. This step is also accomplished in the 
usual fashion by selecting an item from a list of items that leircsent options 
available to the user. Typically the user is presented with a list of options in the 
form of hypertext links, or Universal Resource Locations (URLs). To jump to the 
on-line request page, the user simply selects the on-line request page option by 
clicking the mouse pointer on the associated list item that represents the on-line 
request page option. Once the option is selected, the current list of options is 
replaced by the on-line request page. Control then passes to step 806. 

In step 806, the user specifies a particular on-line request by filling out a 
form that is presented on the on-line request page. This step generally involves 
the user selecting choices from predetennined lists of choices, and/or filling out 
text entiy fields on the on-line request form provided. The type of foTm(s) that 
are provided by the web server 710 in step 806 depends on the specific 
implementation of the present invention. In a simplified implementation, the 
user is presented with simple text entry fields used to specify: (1) the 
identification number<s) of network element(s); and (2) the type of report or 
configuration desired. In a preferred embodiment, the user is provided with the 
tools to 'drill-down' information pertaining to the network elements in a more 
user-friendly manner. In this fashion, network elements can be addressed without 
having specific detailed knowledge about the particular network elements. 

For example, suppose a user does not know the identification number of 
a particular network element that is of interest. This is not an uncommon 
scenario considering that typical long distance providers have control over many 
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thousands of network elements distributed throughout a large geographical area. 
Accordingly, the user is presented with a map that represents die geographical 
area comprising the network. For the purposes of this example, assume that a 
map of the United States is presented. From this map. the user selects a particular 
state. Once a state is selected, the user is presented with a list of sites where 
network elements are located. Once a site is selected, the user is presented with 
a list of network elements within the site. Finally, the user selects one or more 
network elements that is the subject of the request. 

In addition to the above, the user is presented with a list of reports that can 
be generated with the selected network element(s), or a list of configuration 
options that arc available. Note that this is one example of a technique that can 
be used to specify a on-line request in step 806. Many other techniques can be 
used in addition to the example presented above. The choice depends upon the 
specific implementation of the present invention. In any case, once a on-line 
request is formulated in step 806, the user clicks a button to submit the on-line 
request to the web server 710. Control then passes to step 808. 

Note that in addition to an on-line request for a report, authorized users 
can also submit a request to configure one or more network elements within the 
communications network. For example, a user selecting such a request will be 
presented witii a series of choices that represent configuration options that are 
possible for the selected network element(s). Such options include setting the on- 
off status of various performance and/or optical performance alarms, and setting 
or changing alarm threshold parameters for such alarms. 

Next, in step 808, the web server 710 processes the request form 
completed in step 806 and extracts necessary information therefrom. This 
information is tiien formatted for the database 290. For example, the web server 
710 determines from the on-line request: (1) the types of report and/or 
configurations that are desired and (2) the identification numbers of Uic network 
elements that are involved in the request. TTiis information is then fomiatted for 
the database 290. The formatted information is stored to the database 290. 
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In step 810, the scheduler 282 reads the on-line user request from the 
database 290 and translates it into one or more controller work request(s). A 
process that can be used by the scheduler to read and process such requests is 
described below with reference to FIG. 12. Typically this transformation involves 
breaking up the network elements into groups of network elements, where each 
group comprises network elements within the same DCC group 210. In this 
manner, each group can be processed by a controller 271-273 during a single 
telephone call over the switch 56 network 260. Thus, each group is translated 
into a single controller work request. In addition, the telephone number of the 
directly connected network element, such as network clement 244, associated 
with the DCC 210 is specified. Accordingly, a single user request is converted 
into one or more controller work requests. In addition, as described below, each 
controller work request contains a list of all the network elements to be operated 
upon, the type of operation required of each network element, and the time to 
process the request. 

In this exan^)le, an on-line request is desired. Thus, based on the current 
workload of the controllers 271-273, the scheduler determines when the on-line 
request can be serviced the controllers. Typically this is in the form of a 'time 
window' comprising a beginning time and an ending time, as described below. 
If possible, the time window is specified such that the request is processed 
immediately. 

Preferably, controller work requests reside in a shared data table within 
the database 290. The shared data table is referred to herein as a dispatch table. 
The dispatch table contains work requests for each outgoing call via the switch 
56 network 260. As stated, each work request specifies a priority, a time/date 
window, and a list of all of the network elements involved in the work request. 
Work requests are only processed if a controller receives the request within the 
specified time window. For multiple work requests that fall within the same time 
window, the request with the highest priority gets processed firet. Details of the 
dispatch table and such priority processing is presented below. 
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In step 8 12, the scheduler 282 soids status infonnatioD to the user at the 
teiminal 702. This information typically includes an acknowledgment of the 
request, an estimated time for the completion of the request and where to find the 
results. In addition, the scheduler determines whether the user is authorized to 
make the request. If the user is not authorized to make the request, the scheduler 
will not process the request and sends a notification to the web server 710 
indicating that the user is not authorized to perform that function. If however, 
the user is authorized, the scheduler sends infomiation to the user that indicates 
the approximate time that the request will be processed. This estimate is based 
on the cunent workload of the controllers 271-273 and the nature of the request. 
In addition, the user will be presented with information that identifies where the 
results can be found on the web server 710. For example, the user is provided 
some kind of identification that is used to find the report when it is published on 
the web server 710. For example, the web server 7 1 0 may send a messages such 
as The results of the report will be posted on the XXX report page, under the 
heading of Y Y.' Additionally, an e-mail message may be sent to the user upon 
delivay of the report to the web server to notify the user that the report is ready 
to be viewed by the web browser. 

In a preferred embodiment, the user is notified and presented with the 
results in a user request browser window. For example, web browser 
programming tools such as Java* by Sun Microsystems, or ActiveX" by 
Microsoft Corporation, can be used to launch a new thread or applet, when the 
user submits a request. The applet is used to display a new and separate browser 
window which maintains communication links with a web page used to display 
results of the user request. In this fashion, the results page is updated with the 
results of the user request as soon as the results are available. If the user logs off 
the web browser before the results are available, the user may be presented with 
an opUon to re-launch the applet at a subsequent time to view the results of the 
user queiy. In addition to the examples presented, other methods may be used to 
report the results of a user request without departing from the principles disclosed 



wo 97/50210 



PCT/US97/I1007 



. .21- 

herein. Such methods will be apparent to those skilled in the relevant arts. As 
such, the example used herein should not be construed to limit the scope and 
breadth of the present invention. 

Next, in step 814, the controller reads and processes the request. As 
5 described with reference to the flowchart in FIG. 1 2, the controller 271-273 reads 

the request from the dispatch table in the shared database 290. As stated, 
whenever the controllers 27 1-273 are not busy processing requests, (i.e. whenever 
a port 712 is free), additional requests are read from the dispatch table. 
Additionally, the scheduler 282 can designate a request as a high priority request. 

10 Moreover, the scheduler can assign particular requests to particular controllers. 

Accordingly, it may be desired to reserve one or more controllers to process on- 
line requests. In this fashion, it is more likely that high-priority on-line requests 
will be processed in real-time. The number of controllers 271-273 used and the 
use of dedicated controllers depends on the specific needs of the service provider. 

15 An advantage of tte present invention is that the number of controllers 271 -273 

and/or the number of dedicated controllers can be easily altered at any time. In 
addition, it may be desirable to dedicate calain controllers for on-line requests 
during the daytime hours and then un-dedicate those controllers during the night. 
In this fashion, more dedicated controllers are available when numerous on-line 

20 requests arc likely, and more non-dedicated controllers are available when daily 

performance reports are typically generated. 

In step 818, the scheduler 282 stores the results into the database 290. 
This process is further described herein with reference to the flowchart in FIG. 
10. In step 820, the scheduler formats the results data from the database 290 into 

25 Hypertext markup language (HTML) and sends it to the Web server 710. This 

process is further described below with reference to the flowchart in FIG. 1 1 . 
Next control passes to step 822. In step 822, the web server 710 presents results 
to the user as described above. 

FIG. 9 depicts a flowchart of a process that can be used by the controllers 

30 27 1 -273. For the purposes of this example, it is assumed that the controller 27 1 
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is processing a work request that is directed to the DCC group 210. The process 
begins with step 902. In step 902 the controller 271 reads the next request from 
the dispatch table that corresponds with the current time window. As stated, a 
typical controller work request comprises (1) a list of network elements and the 
operations to be perfomcd thereon; (2) a time/date window in which to process 
the request; and (3) the priority of the request. In addition, a specific controller 
identifier can be specified. If this optional field is specified, only the controller 
271-273 that matches the specified identifier can process the request. This field 
in the dispatch table facilitates the use of dedicated controllers, as previously 
described. 

In a preferred embodiment, the controller 271 first searches the dispatch 
table for jobs that fall into the current time/date window and have a high priority. 
If there are no high priority requeste that &11 within the current time window, the 
table is searched for the next priority, and so on. In this fiishion, worit requests 
having higher priorities arc processed before work requests having lower 
priorities. Next, in step 904, the controller 271-273 dials the telephone number 
that is associated with the directly connected networic element, as specified in the 
work request. Using the DCC group 210 as an example, this could be the 
networic element 232 or the networic element 244. For illustrative purposes, it is 
assumed that the networic element 244 is specified in the woric request. Thus, 
dialing this telephone number causes a call to be dispatched into the switch 56 
networic 260 and answered by the networic element 244. Next, the controller 271 
logs on to the computer that resides in the network element 244. 

In step 906, the controller 271 logs on to the next network elemem 
specified in the work request. In step 908, the woric request for the current 
networic element is processed. For example, for a monitor request, performance 
data may be retrieved from the networic element. In the case of a configuration 
request, the current networic element is configured. Next, in step 910, the results 
are stored in atemporary file within the database 290. In step 912, the controller 
271 determines if there any more requests to process for the current network 
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element. If so, steps 908-912 are repeated until a]l requests are processed for the 
current network element. When all requests have been processed for the current 
network element, control passes to step 914. 

In step 914, another shared table referred to as the network element list 
(NE list) is updated to indicate whether or not any errors occurred during the 
processing of the network element just processed. If one or more errors occurred, 
the scheduler 282 re-schedules the work request's for the network element, as 
described below with reference to FIG. 1 0. Next, in step 9 1 6, the controller 27 1 
determines if there are any more network elements to be processed within the 
DCC group 210. If so, steps 906-916 arc repeated unUl all network elements arc 
processed. When all network elements have been processed, control passes to 
step 918. 

In step 918, the current job entry within the dispatch table is updated to 
indicate whether any errors occurred while processing the current job request. 
Specifically, a completion Held in the dispatch table is updated with a value to 
indicate whether: (1) the job has completed successfully; or (2) the job has 
completed with errors. As described below with reference to FIG. 10, if the job 
contains errors, one or more tasks will be lescheduled by the scheduler 282. In 
step 920. the controller 271 teiminates the call. The port 712 that was used to 
process the current work order is now free to process additional work orders. 
Thus, control passes back to step 902, where additional work orders can be 
processed. 

As previously noted, each controUer 271-273 is connected to the switch 
56 network 260 via multiple asynchronous ports 712. Thus, multiple work orders 
can be processed simultaneously by each controller 271-273. This is 
accomplished by running a multitreaded, multitasking operating system on each 
of the controllers 271-273. An example of such an operating system is Windows 
NT* , manufactured by Microsoft Corporation. Accoidingly. multiple instances 
of the controller process depicted by the flowchart in FIG. 9, are simultaneously 
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executed on each of the controllers 271-273. The number of instances coiiespond 
directly with the number of ports 271 on each of the controllers 271-273. 

In the following examples, three separate processes are described with 
references to FIGS. 10, 1 1 and 12. Note that the processes described below are 
each separate and distinct processes that are typically executed independently of 
each other. For convenience, each of the processes is described as being executed 
by the scheduler 282. In one embodiment, this is accomplished by running a 
multitreaded, multitasking operating system such as Windows NT* on the 
scheduler 282. In another embodiment, separate computers are be used to run 
each of the processes described below. In any event, a single scheduler 282 is 
used for exemplary purposes and should not be construed to limit the scope and 
breadth of the present invention. 

An example of a process that can be used to process user requests will 
now be described with reference to the flowchart in FIG. 1 2. The process begins 
with step 1202. In step 1202 the database 290 is searched for the presence of user 
requests. In a preferred embodiment, user requests are stored in a single shared 
request table within the database 290. Thus, the scheduler in step 1 202, scans the 
user request table to determine if outstanding user requests arc present. If so, the 
process continues with step 1204. 

In step 1204, the scheduler 282 translates the user request into one or 
more controller woric request(s). Typically this transformation involves several 
steps. First, the networic elements that are specified in the request are arranged 
into groups that coincide with their DCC group 210. Each set of network 
elements that fall into a single DCC group 210 are converted into a single 
controller work request that can be processed by a controller 271-273 during a 
single 260 switched call. Accordingly, each user request is ttanslated into one or 
more controller work requests. Next, the telephone number of the directly 
connected network element, such as network element 244 is specified for each 
work request. Next, a list of network elements and the operations to be 
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performed thereon is specified. Finally a priority is assigned for each work 
request. For on-line user requests, the highest priority is typically specified. 

Next, in steps 1206 and 1208, the user request is scheduled. This involves 
assigning a time/date window, comprising a beginning time and date and an 
ending time and date for the request. As indicated in step 1206, for off-line 
requests, the deteimination of the time window depends on the cunent work that 
is scheduled for the controllers 271-273 and the requested time specified in the 
user request (if any). As indicated in step 1208. online requests are typically 
scheduled immediately if possible. In step 1210, the completed work reques((s) 
is (are) stored in the dispatch table and control passes to step 1212. In step 1212, 
the scheduler sends status information to the user. As previously described, the 
status can be reported in an E-mail message, on the user request web page, or on 
a separate {^plet-launched user resuh web page. 

A process that can be used to merge data into the master database table in 
the database 290 will now be described with reference to the flowchart in FIG. 1 0. 
The master database table typically contains the latest available information 
pertaining to the network elements within the telecommunications network. This 
table gets updated periodically with the information from the controllers 271-273 
pursuant to processed work requests. The process depicted in FIG. 1 0 is used to 
permanently store results from completed controller work requests into the master 
database table in the database 290. As noted with reference to FIG. 9, immediate 
results from controller work requests are temporarily stored in data files (see step 
910 above) before being merged into the master database table. 

The process begins with step 1002. In step 1002, the scheduler reads the 
next entry in the dispatch table. Specifically, as steps 1002 and 1004 indicate, the 
completion field is read to determine whether or not the work request has been 
completed. If the work request has not been completed control passes to step 
1002. where the scheduler reads the next entry in the dispatch table. As indicated, 
steps 1 002 and 1 004 are repeated until the scheduler fmds a work request that has 
been completed, and control passes to step 1006. 
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Note that in a preferred embodiment of the present invention, the 
controller 271-273 updates the value of the completion field within the dispatch 
table upon the completion of a work request. For example, if a work request has 
completed but contains errors, the value of the completion field is changed from 
T (incomplete) to 'E* (complete, but contains errors). Alternatively if a work 
request has completed with no errors, the completion field is set to a value of F 
(finished with no errors). 

Next, in step 1006, the scheduler 282 determines if any errors have 
occurred by examining the completion field as described above. If no errors 
occurred, control passes to step 1010. If errors occurred, the NE list table, as 
described in step 914 above, is examined to determine which network elements 
caused the errors. Once the Ust of network elements is determined, they are 
rescheduled in another work request. Next, conu-ol passes to step 1010. In step 
1010 data from the work request is stored in the master database table in the 
database 290. The temporary file is then discarded. Finally, control passes back 
to step 1002, where the scheduler searches for the next completed woric request. 
As indicated, this process is repeated continuously. 

A process that can be used to report data to the web server 71 0 for on-line 
requests will now be described with reference to the flowchart in FIG. II. The 
process begins with step 1102. Instep 11 02, the scheduler reads the next entry 
in the dispatch table. Specifically, the status field is read to determine whether 
or not the work request is an on-line request, as indicated by steps 1 1 02 and 1 1 04. 
If the current request in not an on-line request, control passes back to step 1 102. 
As indicated, steps 1 102-1 104 are repeated until an on-line request is found. 
Once an on-line request is found, conU^ol passes to step 1 1 06. 

In step 1 106 the scheduler deteimines whether the results have been 
merged into the master table in the database 290, as described above. This is 
determined by examining a merge-data status field in the dispatch table. If the 
data has not been merged, control passes back to step 1 1 02. If results have been 
merged, control passes to step 1 108. 
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In step 1 108, the scheduler collects the data from the master table in the 
database 290. Next as step 1 1 1 0 indicates, the data collected from the database 
290 is formatted into HTML. Next, in step 1 1 12, the formatted HTML 
document, is sent to the web server 710, so that it can be displayed to the user as 
previously described. 

Generally, a similar process is used to report data for off-line user 
requests. However, in a preferred embodiment, two separate processes are used 
in order to assure that data pursuant to on-line request are processed in a timely 
manner. Typically, the process to report data for on-line user requests is run more 
often than the process used to report off-line requests. For example, the process 
to report data for ofT-line requests may be run every hour, while the process to 
report data for on-line requests is run continuously. Moreover, by separating the 
two processes, the on-line request reporting process can proceed more quickly 
and efficiently. 

In one embodiment, elements of the invention are implemented in one or 
more computer systems operating as discussed herein. For example, controllers 
271-273, scheduler 282, server 284, reporter 286 and elements in DCC group 210 
are implemented using computer systems. An exemplary computer system 602 
is shown in FIG. 6. The computer system 602 includes one or more processors, 
such as processor 604. The processor 604 is connected to a communication bus 
606. 

The computer system 602 also includes a main memory 608, prcieraoly 
random access memory (RAM), and a secondary memory 610. The secondary 
memory 610 includes, for example, a hard disk drive 612 and/or a removable 
storage drive 614, representing a floppy disk drive, a magnetic tape drive, a 
compact disk drive, etc. The removable storage drive 614 reads from and/or 
writes to a removable storage unit 616 in a well known manner. 

Removable storage unit 616. also called a program storage device or a 
computer program product, represents a floppy disk, magnetic tape, compact disk. 
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etc. As will be appreciated, the removable storage unit 616 includes a computer 
usable storage medium having stored therein computer software and/or data. 

Computer programs (also called computer control logic) are stored in 
main memory and/or the secondary mcmoiy 61 0. Such computer programs, when 
executed, enable the computer system 602 to perform the features of the present 
invention as discussed herein. In particular, the computer programs, when 
executed, enable the processor 604 to perform the features of the present 
invention. Accordingly, such computer programs represent controllers of the 
computer system 602. 

In another embodiment, the invention is directed to a computer program 
product comprising a computer readable medium having control logic (computer 
software) stored therein. The control logic, when executed by the processor 604, 
causes the processor 604 to perform the functions of the invention as described 
herein. 

In another embodiment, the invention is implemented primarily in 
hardware using, for example, a hardware state machine. Implementation of the 
hardware state machine so as to perform the ftmctions described herein will be 
apparent to persons skilled in the relevant art(s). 

While the invention has been particularly shown and described with 
reference to prefened embodimients thereof, it will be underetood by those skUled 
in the relevant art that various changes in form and details may be made tiierein 
without departing ftom the spirit and scope of the invention. 
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What Is Claimed Is: 

1 . A system for monitoring and configuring network elements in a 
telecommunications network comprising: 
5 a network management system coupled to the network elements via a 

switched network, wherein the network elements are arranged as a plurality of 
data communication channel groups, each group comprising a plurality of 
network elements, and each group comprising at least one network element that 
is coupled with said switch network via a craft interface port; 
10 a web server coupled to said network management system; 

an computer network coupled to said web server; and 
a plurality of workstations, coupled to said web server via said computer 
network, for user interaction with said network management system, wherein 
each of said workstations communicates with said web server via a web browser 
15 program. 

2. The system of claim 1 , wherein said network management system 
comprises a scheduler, a database and a controller coupled together via a second 
computer network. 

3. The system of claim 1 , wherein said user interaction includes users 
20 submitting a request to said network management system by filling out a pre- 

formatted web page form presented by said web server. 

4. The system of claim 3, wherein said request includes an on-line 
request lo monitor at least one of the network elements in real-time. 

5. The system of claim 3, wherein said request includes a batch 
25 request to monitor at least one of the network elements. 
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6. The system of claim 3, wherein said request includes an on-line 
request to configure at least one of the network elements in real-time. 

7. The system of claim 3, wherein said request includes a batch 
request to configure at least one of the network elements. 

5 8. The system of claim 1 . wherein said user interaction includes users 

navigating through a series of web pages presented by said web server to view 
pre-formatted reports from said network management system. 

9. A method for monitoring and configuring network elements in a 
telecommunications network comprising: 

^® (1) displaying, on a web browser, a formatted user request form for 

accepting user requests to a network nuuiagement system; 

(2) accepting, from said web browser, said user request upon 
submisaon by said user; 

(3) sending information from said user request to said netwoik 
15 management system; 

(4) translating said information into a controller work request; 

(5) processing said controller work request; 

(6) storing results from said controller work request into a database; 

(7) formatting said results for said web browser; and 

(8) sending said results to a web server to be displayed by said web 
browser. 

10. The method of claim 9, wherein said user request is an on-line 
request to monitor at least one network element in real-time. 

1 1. The method of claim 9. wherein said user request is a batch 
25 request to monitor at least one network element. 



20 
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12. The method of claim 9, wherein said user request is an on-line 
request to configure at least one network element in real-time. 

13. The method of claim 9, wherein said user request is a batch 
request to configure at least one network element. 



1 4. The method of claim 1 0, further comprising the step of launching 
a child web browser application program in a separate thread to display results 
from said on-line request. 

1 5. The method of claim 1 2, further comprising the step of launching 
a child web browser application program in a separate thread to display results 
from said on-line request. 

16. The method of claim 9, further comprising the step of sending 
status information to said user to provide infomiation related to the processing of 
said user request. 



1 7. A computer program product, comprising: 

a computer usable medium having computer readable program code 
means embodied in said medium for enabling a processor to manage program 
execution, said computer readable program code means comprising: 

computer readable program code means for enabling the processor to 
display on a web browser, a formatted user request fomi for accepting user 
requests to a network management system; 

computer readable program code means for enabling the processor to 
accept from said web browser, said user request upon submission by said user; 

computer readable program code means for enabling the processor to send 
information from said user request to said network management system; 



wo 97/50210 



PCT/US97/11007 



• -32- 

computer readable program code means enabling the processor to translate 
said information into a controller work request; 

computer readable program code means enabling the processor to process 
said controller work request; 

computer readable program code means enabling the processor to store 
results from said controller work request into a database; 

computer readable program code means enabling the processor to fomal 
said results for said web browser; and 

computer readable program code means enabling the processor to send 
said results to a web server to be displayed by said web browser. 

18. The computer program product of claim 17, wherein said user 
request is an on-line request to monitor at least one network element in real-time. 

19. The computer program product of claim 17, wherein said user 
request is a batch request to monitor at least one network element. 

20. The computer program product of claim 17, wherein said user 
request is an on-line request to configure at least one network element in real- 
time. 

21 . The computer program product of claim 17, wherein said user 
request is a batch request to configure at least one network element. 



22. The computer program product of claim 1 8, further comprising 
means enabling the processor to launch a child web browser application program 
in a separate thread to display results from said on-line request. 
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23. The computer program product of claim 20, fiirther comprising 
means enabling the processor to launch a child web browser application program 
in a separate thread to display results from said on-line request. 

24. The computer program product of claim method of claim 17, 
5 further comprising means enabling the processor to send status information to 

said user to provide information related to the processing of said user request. 

25. A system for automatically configuring network elements, the 
system comprising: 

means for receiving a request from a user to configure a first network 
10 element in a network arranged as a plurality of data communication channel 

groups, each data communications channel group including a plurality of network 
elements that are interconnected by a plurality of data communication channel 
links; 

means for identifying a data communication channel group that includes 
15 said first network element; 

means for identifying a second network element in said data 
conununication channel group that is directly connected, via a crafi interface port 
on said second network element, to a routing network; and 

means for directing a controller to initiate a call to said second network 
20 element, wherein said controller sends data from said user from said first network 

element via data communication channel links between said second network 
element and said first network element. 

26. The system of claim 25, wiierein said request is for setting the on- 
off status of a network element performance alarm. 



27. The system of claim 25, wherein said request is for setting the 
threshold parameters for a network element performance alami. 
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28. The system of claim 25, further comprising a means for 
automatically generating a series of instiuctions that allows said configuration 
means to navigate through a series of menu screens. 

29. The system of claim 25, wherein said request includes script 
information that directs said configuration means to navigate through a series of 
menu screens. 



30. The system of claim 25, further comprising a means for scheduling 
a periodic series of requests for configuring the network elements in the network. 

31. The system of claim 30, wherein said periodic series of requests 
include requests for sc^ng the on-ofT status for performance alanns. 

32. The system of claim 25, further comprising: 
means for emulating a computer terminal; and 

means for retrieving data from a network element via a screen scraping 
method performed on data received by said computer terminal. 

33. A method for configuring network elements, the method 
conqnising the steps of: 

(1) receiving a request from a user to configure a first networic 
elemcm in a network arranged as a plurality of data communication channel 
groups, each data communications channel group including a plurality of network 
elements that are interconnected by a plurality of data communication channel 
links; 

(2) identifying a data communication channel group that includes said 
first network element; 
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(3) identifying a second network element in said data communication 
channel group that is directly connected, via a craft interface port on said second 
network element, to a routing network; and 

(4) directing a controller to initiate a call to said second network 
element, wherein said controller retrieves data requested by said user from said 
first network element via data conununication channel links between said second 
network element and said first network element. 

34. The method of claim 33, wherein said step (1 ) comprises the step 
of receiving a request from a user to set the on-off status of a network element 
perfomfiancc alarm. 

35. The method of claim 33, wherein said step (I ) comprises the step 
of receiving a request from a user to set network element alarm threshold 
parameters. 

36. The method of claim 33, further comprising the step of: 

(5) generating a scries of instructions that allows said controller to 
navigate through a series of menu screeas. 

37. The method of claim 33, wherein said step (1) comprises the step 
of receiving a request from a user that includes script information that directs 
controller to navigate through a series of menu screens. 

38. The method of claim 33, further comprising the step of: 

(5) scheduling a periodic series of requests to set on-off performance 
alarm status for network elements in the network. 



The method of claim 33, further comprising the step of 
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(5) scheduling a periodic series of requests to set alarm threshold 
parameters for network el«nents in the network. 



40. The method of claim 33, iiirther comprising the steps of: 

(5) emulating a computer terminal; and 

(6) retrieving data from a network element via a screen scraping 
method performed on data received by said computer terminal 

41 . A computer program product, comprising: 

- a computer usable medium having computer readable program code 
means embodied in said medium for enabling a processor to manage program 
execution, said computer readable program code means comprising: 

computer readable program code means for causing a computer to receive 
a request from a user to configure a first network element in a network arranged 
as a plurality of data communication channel groups, each data communications 
channel group including a plurality of network elements that are interconnected 
1^ a plurality of data communication channel links; 

computer readable program code means for causing a computer to effect 
an identification of a data communication channel group that includes said first 
network element; 

computer readable program code means for causing a computer to effect 
an identification of a second network element in said data communication 
channel group tfiat is direcUy connected, via a craft interface port on said second 
network element, to a routing network; and 

computer readable program code means for causing a computer to direct 
a controUer to initiate a call to said second network element, wherein said 
controller retrieves data requested by said user from said first network elemem via 
data communication channel links between said second network element and said 
first network element. 
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42. A system for retrieving network element data, the system 
comprising: 

means for receiving a request from a user to retrieve data from a first 
network element in a network arranged as a plurality of data communication 
5 channel groups, each data conununications channel group including a plurality 

of network elcmaits that arc interconnected by a plurality of data conununication 
channel links; 

means for identifying a data communication channel group that includes 
said first network element; 
^0 means for identifying a second network element in said data 

communication channel group that is directly connected, via a craft interface port 
on said second network element, to a routing network; and 

means for directing a collector means to initiate a call to said second 
network element, wherein said collector means retrieves data requested by said 
15 user from said first network element via data communication channel links 

between said second network element and said first network element. 

43. The system of claim 42, wherein said request is a request to 
retrieve card-level inventory data. 

44. The system of claim 42, wherein said request is a request to 
20 retrieve quadrant layout information. 

45. The system of claim 42, furdier comprising a means for generating 
a series of instructions that allows said collector means to navigate through a 
series of menu screens. 



25 



46. The system of claim 42, wherein said request includes script 
information that directs said collector means to navigate through a series of menu 
screens. 
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47. The system of claim 42, further comprising a means for scheduling 
a periodic series of requests to retrieve configuration information from the 
network elements in the network. 

48. The system of claim 47, wherein said configuration information 
includes card-level inventory data or quadrant layout information. 

49. The system of claim 42, further comprising: 
means for emulating a VTl 00 tenninai; and 

means for retrieving data from a network element via a screen scraping 
method. 



50. A method for retrieving network element data, the method 
comprising the steps of: 

(1) receiving a request from a user to retrieve data from a first networic 
element in a networic arranged as a plurality of data communication channel 
groups, each data communications channel group including a plurality of network 
elements that are interconnected by a plurality of data communication channel 
links; 

(2) identifying a data communication channel group that includes said 
first network element; 

(3) identifying a second networic elancnt in said data communication 
channel group that is directly connected, via a craft interface port on said second 
network elemmt, to a routing network; and 

(4) directing a collector means to initiate a call to said second network 
element, vi^erein said collector means retrieves data requested by said user from 
said first network element via data communication channel links between said 
second network element and said first network element. 
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5 1 . The method of claim S0» wherein said step (1 ) comprises the step 
of receiving a request from a user to retrieve card-level inventory data. 

52. The method of claim 50, wherein said step ( 1 ) comprises the step 
of receiving a request from a user to retrieve quadrant layout information. 

53. The method of claim 50, further comprising the step of: 

(5) generating a series of instmctions that allows said collector means 
to navigate through a series of menu screens. 

54. The method of claim 50, wherein said step (1 ) comprises the step 
of receiving a request from a user that includes script information that directs said 
collector means to navigate through a series of menu screens. 

55. The method of claim 50, further comprising the step of: 

(5) scheduling a periodic series of requests to retrieve configuration 
information from the network elements in the network. 

56. The method of claim 55, wherein said step (5) comprises the step 
of scheduling a periodic series of requests to retrieve card-level inventory data or 
quadrant layout information. 

57. The method of claim 50, further comprising the steps of: 

(5) emulating a VTl 00 terminal; and 

(6) retrieving data from a network clement via a screen scraping 
method. 



58. A computer program product, comprising: 
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a computer usable medium having computer readable program code 
means embodied in said medium for managing program execution, said computer 
readable program code means comprising: 

computer readable program code means for causing a computer to receive 
a request from a user to retrieve data from a first network element in a network 
arranged as a plurality of data communication channel groups, each data 
communications channel group including a plurality of network elements that are 
interconnected by a plurality of data communication channel links; 

computer readable program code means for causing a computer to effect 
an identification of a data communication channel group that includes said first 
network element; 

computer readable program code means for causing a computer to effect 
an identification of a second network element in said data communication 
channel group that is directly connected, via a craft interface port on said second 
network element, to a routing network; and 

computer readable program code means for causing a computer to direct 
a coUector means to initiate a call to said second network element, wherein said 
collector means retrieves data requested by said user from said first network 
element via data communication channel links between said second network 
element and said first network element. 
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